Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[WIP] Support renaming viewmodel classes in migrations #182

Open
wants to merge 11 commits into
base: master
Choose a base branch
from

Conversation

chrisandreae
Copy link
Member

@chrisandreae chrisandreae commented Aug 9, 2022

If a viewmodel class changes name, migrations become a lot harder: clients specifying the old name in their X-ViewModel-Versions will be ignored, old client views won't be migrated up, and new server views won't be migrated down. This can only be partially mitigated by doing the migration in a parent view: it would have to use the parent view version change as a proxy for the child view+name change.

Instead, provide first class support for declaring that a migration changes a view's name with renamed_from :Foo

@chrisandreae chrisandreae marked this pull request as ready for review August 10, 2022 06:17
Copy link
Contributor

@thefloweringash thefloweringash left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, small number of comments.

lib/view_model/registry.rb Show resolved Hide resolved
lib/view_model/migrator.rb Outdated Show resolved Hide resolved
lib/view_model/migratable_view.rb Outdated Show resolved Hide resolved
test/unit/view_model/active_record/migration_test.rb Outdated Show resolved Hide resolved
chrisandreae and others added 6 commits August 18, 2022 11:34
Co-authored-by: Andrew Childs <andrew.childs@bibo.com.ph>
To identify a migrated schema version for caching purposes, we need to use both
the current and target schema versions. Otherwise if we were to make future
migrations that would affect the result when migrating to older views (e.g. by
discarding and reconstructing data), the cache would not be invalidated and
cached results would be different from computed ones.
@chrisandreae
Copy link
Member Author

So there are two issues that are blocking this:

1: registering the historical names and versions in the registry at register/resolve_deferred_classes time is insufficient. The deferral is meant to be for long enough to a class to set the view_name. It's quite common within the body of a viewmodel class to end up hitting for_view_name and therefore resolving the deferred classes, including itself. If this happens before the migrates blocks, it'll be registered without any of its historical versions.

A possible solution to this would be to split the deferral in two, to resolve the class name and the historical versions independently. Then, migrates could validate that the latter resolution hasn't happened, effectively banning lookup of old versions (that would cause resolution) during the body of the class.

2: View aliases. Presently, alias names aren't registered at old versions at all, which is simply insufficient. But also, if a view has aliases, we don't know when they're valid from. We might have to extend the renamed_from to have multiple histories, and support something like renamed from: 'ParagraphView', to: 'NewParagraphView' to rename a non-default name. Then the old versions could be computed for all the alias names.

Alternatively, the alias names only exist for the MTI subclassing, which we don't like and wish we didn't have any more. If we were to implement #165, we could go ahead and release https://github.com/iknow/eikaiwa_content/pull/1598 which would remove the need for aliases, and we could drop that feature entirely.

@chrisandreae
Copy link
Member Author

Alternative approach to (1) that would require less careful maintenance of the deferred structures:

Rather than the registry maintaining the full map of name -> version -> class, it could instead have

  • a map of current-canonical-name -> class
  • a map of historical-name -> [classes], sorted by descending highest version

At construction time you need to make sure there is no version overlap.
Then when resolving at a certain version, you take the first class that agrees that it responds to that version.
When resolving at no-version-specified, you only take the current canonical name.

Then because not all the version resolution is done eagerly, the only “deferred” step has to be adding the main class name, and that only needs to be deferred until the class name actually exists.

Alias names and historical names can be added immediately: at the time a view_alias call or a migrates { renamed_from: } is encountered.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants